A gigabit-capable passive optical network (GPON) or a 10-gigabit-capable passive optical network (XG-PON) system generally include three parts: an optical line terminal (OLT) at a central office end, an optical distribution network (ODN), and an optical network terminal (ONT). Multiple ONT devices may be connected to GPON ports of a same OLT by using the ODN, where a natural broadcast mode is used on a downlink, and a time division multiplexing mode is used on an uplink. An ONT management and control interface (OMCI) is an interface specification defined in GPON standards, for managing an ONT by an OLT. When the ONT registers with the OLT, an OMCI channel is established, and an OMCI message is transmitted between the OLT and the ONT through the established OMCI channel. The OMCI is a master-slave management protocol, in which the OLT is a master device and the ONT is a slave device. Through OMCI channels, the OLT controls multiple ONT devices connected to the OLT. In the OMCI protocol, various resources and services of the ONT managed by the OLT are abstracted into a protocol-independent management information base (MIB), where a basic information element in the management information base is a management entity (ME), and an instance is specific implementation of the managed entity. In the OMCI message delivered to the ONT, the OLT manages and controls the ONT by performing an operation, such as Create/delete Delete/set Set/Get, on a managed entity specific instance.
The OMCI standard is specified by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T). It defines in detail entities and attributes related to ONT configuration, fault management, and performance statistics in an optical access system. With development of a GPON application, the OMCI standard is also evolved continuously. In standards of new versions, there may be cases in which a managed entity is added, or a management entity or a management entity combination used for a same function is replaced with another new managed entity or managed entity combination, and there are cases in which ONTs produced and delivered in different time periods comply with standards of different OMCI protocol versions. Therefore, a great challenge is imposed to compatibility of an OLT with an ONT of a history version in a live network. In addition, in an evolution process of the OMCI standard specified by the ITU-T, to meet customer requirements, device vendors make private extensions of functions based on different version baselines; and based on ITU-T standards, add some managed entities according to service requirements, and supplement new ITU-T standards with definitions of managed entities for a same function. However, for the same function, managed entity definitions added by different operators may be different, and managed entity definitions added by operators may be different from managed entity definitions added later by the ITU-T. Therefore, for the same function, when an OLT needs to be interconnected with ONTs from different vendors or ONTs that comply with standards of particular operators, there are multiple choices of configured OMCI managed entities. This imposes a greater challenge to interoperability.
In the prior art, when an OLT manages ONTs that are of different hardware types or support different OMCI protocol versions, for a same function, the ONTs are configured and managed by using different command lines, and different command lines are correspondingly used to configure different command lines. Because there are multiple sets of command lines, management complexity and costs are increased. If a same command line is used for a same function when the OLT manages the ONTs of different hardware types or different OMCI protocol versions, the OLT determines, according to the OMCI protocol versions supported and reported by the ONTs and extended entities supported by the ONTs, a manner for sending corresponding OMCI managed entities to the ONTs. In this way, when ONTs of a same hardware type need to adapt to different markets, customization is required. For example, for an ONT of type A, if a network entry test is required by operator a, the ONT of type A needs to comply with a specification of operator a, and an entity extended by operator a needs to be customized and reported, but in markets of other operators, entities extended by the other operators instead of operator a need to be reported. Therefore, a large quantity of ONTs needs to be configured, which affects ONT production and delivery.